\chapter{Evaluation}\label{cha:evaluation}
The main 
goals of  this thesis are to design and to implement an architecture for Wi-Fi
sharing in a peer-to-peer way. In this chapter, we evaluate and discuss 
the result of our work. We firstly evaluate our implementation
against the requirements specified in Chapter \ref{cha:requirements}, then 
we will do some
performance tests to our implementation in order to  check the efficiency of our
model.
\section{Evaluation against Requirements}
This section addresses the requirements introduced in Chapter
\ref{cha:requirements}. As
mentioned in the previous chapters, our work is based on the HIPL
implementation, i.e. the security is provided by the IPsec BEET mode and
the authentication comes along with the BEX of HIP. Other possible features
like mobility and multihoming are also provided by HIP. At time of
implementation, the HIPL supported HIP base draft version 08
\cite{hip_draft} and HIP
mobility and multihoming draft version 05 \cite{hip_mm} with limited mobility support
for client host in NATted environments. 
\subsection{Test and Development Setting}
We use system level testing to evaluate the implementation against
requirements. The system was tested in real networks and we 
assume that the home router is reachable under a public IPv4 address,
whereas the access router may have a private IP address.
In this case, the access router will not be reachable from outside and
cannot act as home routers for its owner.

In the testing environment, we use a Linux laptop with an Intel Celeron M
370 CPU (1.5Ghz) and 1
GB memory as mobile client, a wireless
router (Netgear 634U, Broadcom 5265 CPU with 200Mhz and
16MB RAM) as middlebox. The computer as endpoint at home (home router) is a Linux laptop
with Intel Celeron 2.60GHz CPU and 265 MB memory. 
Another middlebox is needed for the test of mobility. 

The kernel running on the mobile client and the home router is of version 2.6.22
with patched IPsec BEET mode module. The userspace program HIP daemon  running 
on both
sides is the modified and extended version as described in the chapters of
design and implementation. If only acting as access router, there is no need
for the middlebox to be HIP-capable, since all it needs are the kernel
module \texttt{ip\_queue}, the user space library \texttt{libipq}  and the
OpenSSL library for verifying the signatures and the certificates.
\subsection{User Access Control}
In our approach, the user access control is totally decentralized in a
peer-to-peer way. Only the certificate of the home router must be issued by
a CA of the community, this could be done at registration phase. The middlebox
program only forwards the traffic to one's home router.
So people who share
their bandwidth with others do not need to worry about the liability
issues. People who use an access router for Internet logically use their own
router should be responsible for their own Internet activities.

In practice, the user access control features were tested with the test
setting described earlier. The current madwifi driver \cite{madwifi} for Atheros 
based wireless cards supports concurrent multiple access points for a single
physical device. Each of these access points is called a \emph{virtual
access point} (VAP). VAPs are limited to share the same channel and the
underlying physical hardware, but this kind of abstraction provides a
better way of access control.  
We created an open virtual access point for nomadic users. Firewall rules 
ensure that nomadic users only have access to the subnet of the open VAP. From
the VAP, only UDP traffic with destination port number of 50500 is allowed.

The test for user access control was successfully accomplished. On getting 
an
IP address from a VAP, the mobile user can only establish a HIP association
to this home router or other providers based on the token.
Every other activities are discarded by the access
router. 
\subsection{Confidentiality}
We tested the confidentiality issues with the \texttt{tcpdump} program in the access
router. This can also be done by using a laptop with a monitor mode Wi-Fi
card to simulate an attacker.

The HIP handshakes can be observed by an attacker, but due to the security
of the Diffie-Hellman key exchange which is used in the HIP Base Exchange,
an attacker will not be able to eavesdrop the shared secret used in the
communication.

As shown in the \texttt{tcpdump}, all traffic after the Base Exchange is
UDP-encapsulated ESP traffic and cannot be eavesdropped by attackers.
\subsection{Legal Issues}
The legal issues regarding the Wi-Fi liability as described above are
solved
by establishing the HIP-tunnel to the home router (provider) in the standard mode
and through the ``hashed'' logging in the optimized mode. These two methods
will be tested.

In the standard mode, while accessing the Internet, the mobile user
uses logically the IP address of his home router. 
As shown in websites like \url{http://www.ip-adress.com/}, the mobile user
logically uses the IP address of the home router.

In the optimized mode, if the activities of a user are logged, the content
of the log files is only the hash value of the IP address. But it provides
interface to inquire whether a user represented by a HIT at what time has visited an IP
address.

\subsection{Mobility}
Due to the problems described in section \ref{sec:imp_state}, the
mobility is tested with the following environment:

There are two wireless routers: A and B, in each of them the middlebox
program is running. Firstly, the mobile user establishes HIP association
with the home router, and testes the connection with \texttt{netcat6}.
Then the mobile user disconnects himself from router A and gets connected
with the router B. The netcat6 connection remains which demonstrates that
the mobility works. The outputs of the two routers show that middlebox
program controls the traffic access as described in the design sections. 
\section{Performance Analysis}
In the previous section we presented our functionality tests. In this
section we will measure the performance of our model. As described in the
design and implementation chapters, our tunneling program uses a scheme of  
\emph{IPv4 in IPv6 then IPv6 to IPv4} tunneling. We will
measure the performance in comparison with the normal Wi-Fi Internet access
(the FON approach).

\subsection{Authentication Time}
In the FON model, after getting connected with an AP, a user is prompted to
authenticate himself  in a SSL-protected website. The Internet access is only
granted after a successful authentication. This procedure will take,
depending on the configuration, at least  5 to 10 seconds.

In our approach, the authentication is very efficient. The time it takes is as
long as the BEX time. The only bottleneck is the public key
related operation in the middlebox, because the middlebox must verify three times
signature (one certificate and the two nonces). We performed some measurements to
measure the  time for the authentication. Both peers are using 1024 bits
long DSA public keys as HI.

The function we used to measure time is \texttt{gettimeofday}. We recorded the
time of sending the I1 packet as start time and the time on reaching the
\emph{established} state as stop time. The value was only written into file when the Base
Exchange has completed so that the time for disk writing will not be
included in the measurements. The value we gained from the test is the mean value of 150
samples. The mean time for the authentication is 741 ms with a standard
deviation of 385 ms. 

We also measured the time which is needed for the middlebox to perform 
a DSA signature verification. The value
we gained from the test
is the mean value of 50 samples. The mean time for the DSA verification on
the middlebox is 90 ms with a standard deviation of 18 ms. 

As described in section \ref{sec:mobility_def}, in the Update 
process, the middlebox must perform
three PK operations to verify the certificate and the signature of the
nonces. Based on the measured result for the Base Exchange and the DSA
verification time on the middlebox, we can estimate that the Update process
will take about 300 ms.

\subsection{Throughput}
After a successful authentication, an ESP tunnel is established between the
communication peers to transfer the payload securely. In the following
subsection, we present the measurements of the throughput of our model in
comparison to the direct Wi-Fi access like in the FON model.

We use the program \texttt{iperf} as testing tool. \texttt{iperf} is a tool
for measuring the maximal TCP bandwidth \cite{iperf}. The test setting is
described in Figure \ref{img:iperf} as follows:
\begin{figure}[htb]
 \centering
 \includegraphics[width=12cm]{pics/test_setting}
 \caption{Test setting for throughput and latency
 }
 \label{img:iperf}
\end{figure}
\begin{itemize}
\item The mobile client is connected with the access point.
The computer in which
the program \texttt{iperf} runs in server mode, which we call the
iperf-server, is located in the same
subnetwork with the computer acting as home router and the access point.
\item We firstly measured the maximal bandwidth between the mobile client
and the \texttt{iperf}-server (direct test as depicted in Figure
\ref{img:iperf}).
\item We then measured the maximal bandwidth between the mobile client
through a HIP tunnel with the home router as endpoint to 
the \texttt{iperf}-server (test over the HIP tunnel as depicted in Figure
\ref{img:iperf}.
\end{itemize}
We firstly measured the bandwidth where there was no limitation of the
bandwidth, in our case the maximal bandwidth is 54 Mbit/s. The mean throughput in the
direct mode was 31.6 Mbit/s with a standard deviation of 0.17 Mbit/s. 
The mean
throughput in the tunneling mode was 1.6 Mbit/s with a standard deviation of
0.23 Mbit/s. As tested in
\cite{ipv4_hip}, especially the interfamily transformation and the NATted
network environment will
throttle the throughput. 
Also the MTU of the TUN device must be reduced to meet the minimal MTU of
IPv6 packets, as described in section \ref{sec:tun}.
But this  is inconsistent with the Wi-Fi sharing reality, therefore we
made 
another test with the following assumptions which
meet the reality of Wi-Fi sharing:
\begin{enumerate}
\item An access router provides 512K bandwidth for the others to share,
which is the default value of the FON model.
\item The upload link of the home router is also 512K, so that the maximal
throughput is 512K.
\end{enumerate}
The throughput of our model under these assumptions is good. The mean
value of the throughput is 418 Kbit/s with a standard deviation of 8.7 Kbit/s,
whereas in the direct mode, the mean value for throughput is 436 Kbit/s
with a standard deviation of 15.6 Kbit/s. This shows that our model
provides a good throughput for Wi-Fi sharing.
\subsection{Latency}
As described in section \ref{sec:tunneling}, a packet for the Internet will be
firstly encapsulated in a IPv6 packet, which will then processed by the
IPsec BEET mode module and the IPv6 packet is transformed in a IPv4 packet.
The packet is sent to the peer over the wire. The process is reversed on 
the other side
on receiving the packet. 

Generally, the latency consists of the following parts, as shown in Figure
\ref{img:latency}:
\begin{figure}[htb]
 \centering
 \includegraphics[width=12cm]{pics/latency}
 \caption{Latency in our tunneling model
 }
 \label{img:latency}
\end{figure}

\begin{enumerate}
\item The time for UDP encapsulation, IPsec processing and the inter-family
transformation on the mobile client, which we call phase I in the Figure
\ref{img:latency}.
\item The time for the transmission in the HIP tunnel, which we call phase
II in Figure  
\ref{img:latency}.
\item The time for IPsec processing and the interfamily
transformation and the UDP decapsulation on the server side which we call
phase III in Figure
\ref{img:latency}.
\end{enumerate}
We measured the latency in the same subnetwork as shown in Figure
\ref{img:latency}. The RTT (round-trip time) given here is the
mean value of 500 samples. The mean RTT in the standard mode is 4.09 ms with
a standard deviation of 3.02 ms. By using the HIP tunnel, the mean RTT is
5.70
ms with a standard deviation of 3.11 ms. Thus we can estimate that the phase
of 1 and 3 in for packet processing will take about 2 ms. In practice, the
time needed for phase II  will be the most crucial factor for latency
critical applications like VoIP.
\section{Discussion}
The evaluation shows the functionality of our design and implementation.
The performance tests show that our model is efficient for Wi-Fi sharing
purpose. However, for the highly desired feature like mobility handover for
voice application over Wi-Fi networks, there are still areas for
improvements.

The authentication time is satisfactory for most scenarios. The handover
time may be too much for applications like VoIP. The reason is that we only 
estimated one part of the
handover process, namely the time for sending the first \emph{Update} message to
send the third \emph{Update} packets. Another part of the update process,
namely the time used for switch from one access point to another is not
measured. 

According to \cite{hearing}, for VoIP application, the delay that occurs
during handoff cannot be more than 50 ms, otherwise it will be detected
by human ear. Both the current handoff procedure and our model for Wi-Fi
sharing should be improved so that the time of the whole handoff can be 
reduced.

One possible solution to improve the performance of the handoff is to use the
RSA algorithm to sign and verify the signatures. Since we only implemented
the DSA scheme, we estimate the time which is needed based on the
result for the \texttt{openssl speed} program, as shown in table
\ref{tb:openssl}.
\begin{table}
\begin{tabular}{|l|c|c|c|c|}
\hline
        &          sign  &  verify &   sign/s &verify/s \\\hline 
rsa 1024 bits& 0.150000s& 0.005359s &     6.7 &   186.6\\ \hline 
rsa 2048 bits& 0.663333s& 0.015613s &     1.5 &    64.0\\ \hline 
rsa 4096 bits& 3.693333s& 0.052421s &     0.3 &    19.1\\ \hline \hline
dsa 1024 bits& 0.051414s& 0.063677s &    19.5 &    15.7\\ \hline 
dsa 2048 bits& 0.153385s& 0.180000s &     6.5 &     5.6\\ \hline
\end{tabular}
\caption{OpenSSL speed on processing PK operations on a Netgear WGT634U
wireless router}
\label{tb:openssl}
\end{table}
In RSA, verifying a signature takes much less time than signing a file. Thus
this approach will help if the home router is a powerful PC server which
signs packets quickly. Otherwise if the home router is also an embedded router
like the access router, the processing time will also be similar because 
the responder must sign each packet according to
the protocol. 
\section{Summary}
At first, this chapter analyzed the implementation of our peer-to-peer Wi-Fi
sharing model in relation to the requirements specified in Chapter
\ref{cha:design}. The implementation satisfies the requirements defined 
for it. Then we measured the time needed for authentication and
the performance in areas like throughput and latency. The authentication
time is satisfactory, but the time for mobility handover will be long for
applications like VoIP. The throughput of our model is sufficient for Wi-Fi
sharing purpose.
